Electronic circuits, such as integrated circuits, are used in a variety of products, from automobiles to microwaves to personal computers. Designing and fabricating these circuits involves many steps, known as a “design flow.” The particular steps of a design flow often are dependent upon the type of circuit being designed, its complexity, the design team, and the circuit fabricator or foundry that will manufacture the circuit. Typically, software and hardware “tools” will test a design at various stages of the design flow. The results of this testing then are used to identify and correct errors in the design. These testing processes are often referred to as verification, validation, or testing.
In some instances, verification will be facilitated by simulating the operation of the design using software, such as, for example, the QUESTA family of simulators available from Mentor Graphics Corporations of Wilsonville, Oreg. Electronic design simulators determine, using software executing on a computer, what the various states of an electronic design would be when presented with some input stimulus. Some designs however, may be too large or complex to efficiently simulate using software. Instead, the functionality of the circuit design will be verified by emulating the circuit design using a hardware emulator. Examples of hardware emulators include the VELOCE family of emulators available from Mentor Graphics Corporation of Wilsonville, Oreg., the ZEBU family of emulators available from EVE SA of Palaiseau, France, and the PALLADIUM family of emulators available from Cadence Design Systems of San Jose, Calif. An emulator typically will provide a set of configurable components for mimicking the operation of a circuit design. For example, emulators that use field-programmable gate array circuits can emulate the functionality of a circuit design using a combination of state elements, memories and lookup tables. Of course, other types of emulators may provide additional or alternate primitive components. For example, an emulator may function by using combinatorial elements computing a selectable function over a fixed number of inputs.
Modern integrated circuit designs often include pre-designed reusable components, referred to as “intellectual property” or “IP”, herein referred to as “proprietary components.” These proprietary components are often purchased or licensed from a third party. For example, if the integrated circuit is to include an analog to digital converter. A proprietary component for an analog to digital converter can be licensed from a third party vendor and then included in the design for the integrated circuit. This will save the designers from having to design their own analog to digital converter. These proprietary components can be described in a variety of formats usable by a circuit designer or design tool. For instance, a proprietary component may be described in a high-level description language (such as VHDL or Verilog), RTL, a netlist, a gate-level representation, or any other representation that is usable in the design flow. Furthermore, a proprietary component is often at least partially encrypted in a manner that allows them to be used by design and verification tools in the design flow, but does not allow the circuit designer to access or otherwise view the internals of the proprietary component.
Although these proprietary components have been pre-designed and are often free from errors or defects, this is not always the case. This is especially true where early access to the proprietary component is given to the integrated circuit designer before the third party vendor has fully verified the design. Any errors in the proprietary components will then be manifest during verification of the integrated circuit design that incorporates the proprietary component. Often, these errors only manifest after a complex sequence of operations are applied to the integrated circuit design during verification. In many cases, many billions of cycles of operation are required to be verified before the errors in the proprietary component manifest themselves.
As can be appreciated, the designers of the integrated circuit may not have the necessary understanding of the internals of the proprietary component to properly debug the errors. Furthermore, even if the designers of the integrated circuit did have the necessary understanding, they are often not given the ability to view the internal design of the proprietary component except at boundary signals or selected internal registers. As such, debugging the proprietary component would still not be possible. Typically this is due to security concerns around the design of the proprietary component. Similarly, the designers of the proprietary component often do not have access to the design for the integrated circuit that incorporates the proprietary component, since the design owner has security concerns similar to the third party vendor of the proprietary component. Furthermore, even if the proprietary component designers had access to the incorporating design, they may not have an ability to exercise the incorporating design in an environment that would allow the errors in the proprietary component to manifest.
Conventionally, in order to allow the third party vendor to debug a suspected problem in the proprietary component, a sequence of inputs is generated by the designers of the overall circuit. The input sequence corresponds to signal values applied to the inputs of the proprietary component during verification. Subsequently, the input sequence is sent to the third party vendor, who can then use the input sequence in a standalone verification environment for the proprietary component. As those of ordinary skill in the art will appreciate, these signal values are often captured from signal lines internal to the integrated circuit design during verification. Furthermore, since many billions of cycles of operation must be verified before the error is manifest, the input sequence will then correspond to these many billions signal values captured during verification. As a result, it is often impractical to construct the input sequence needed to reproduce the error in the proprietary components since the internal signal lines corresponding to the proprietary components inputs would need to be monitored and then the signal values on these signal lines would need to be captured for the many cycles of operation needed to reproduce the error.